The Traffic Engineering (TE) tunnel may provide a reliable Quality of Service (QoS) mechanism. It guarantees the bandwidth and supports features such as affinity, explicit path, and preemption. In addition, the TE tunnel has a backup protection mechanism, such as partial protection (fast re-routing) and end-to-end protection (including hot standby protection and tunnel group protection).
Because the current TE tunnel is unidirectional, it cannot support some specific scenarios, thus failing to meet some specific requirements.
For example, when a Resource Reservation Protocol—Traffic Engineering (RSVP-TE) tunnel and a multicast service need to be deployed on a same network, the multicast function may be affected if multicast traffic is carried on the TE tunnel, that is, when multicast packets are forwarded through the TE tunnel.
As shown in FIG. 1, a forward TE tunnel is established from router A (RTA) to router C (RTC). When a multicast signaling packet is sent from RTA to RTC, the multicast signaling packet goes through the TE tunnel. Thus, router B (RTB) does not process the multicast packet, nor does it have related multicast forwarding entries. When the traffic is returned from router D (RTD) to RTA through RTC and RTB, the traffic can reach RTA only when it undergoes the IP forwarding by RTB. RTB, however, does not have multicast forwarding entries. Thus, the multicast traffic is lost.